Field
The present invention relates generally to the field of computers and computer devices. More particularly, the present invention relates to a computer device and a method for controlling untrusted access to a peripheral device.
Description of Related Art
There is an on-going need to protect computer devices from malicious activity, as is well recognised in the field of computer security. In particular, it is desired to protect computer devices from attacks against peripheral devices, such as malicious access to a webcam or a microphone.
Generally, a peripheral device connects to and works with the computer device as an auxiliary, to provide an additional capability beyond the ordinary abilities of the computer device. Peripheral devices typically provide an auxiliary input, output and/or storage functions. For example, peripheral devices for input functions typically include keyboards, mice, cameras (webcams) and microphones. Peripheral devices with output functions may include displays, printers and speakers. Some devices, such as modems and network interface controllers, may be both input and output peripheral devices. Storage devices, such as DVD drives and solid state memory (Flash drives), may be provided as peripheral devices. Peripheral devices are typically physically separate devices which are located external to a main housing or casing of the computer device and are connected via an appropriate local physical interface (e.g. a USB port). However, it is also known to provide peripheral devices which reside within the computer device or are physically integrated with the computer device.
A challenge arises in that malicious code (malware) may hijack a peripheral device for unauthorised purposes, such as to obtain personal or confidential information. Peripheral devices are typically user-driven, such that applications receive input from or send output to the peripheral devices only in response to interaction or command by a user. However, malicious software may access the peripheral devices even in the absence of any interaction from the user. In practice, malware may access the peripheral devices through relevant calling functions (e.g. through a device API), independently of any request originating from the user. For example, malicious software may access a webcam connected to the computer device and monitor or record the user or an environment of the computer device without any knowledge of the user. Additionally, such malicious software may access a microphone connected to the computer device and also surreptitiously monitor or record the user or their surroundings. Further, malware may access a keyboard connected to the computer device and covertly record keystrokes, which may be analysed for sensitive data such as passwords or bank account details. Still further, malware may monitor when peripheral devices are connected to the computer device and then secretly access, for example, a content of a flash drive temporarily connected to the computer device. Alternatively, malicious software may access the peripheral devices through intentional or non-intentional user interaction. For example, malicious software may exploit user interactions in an untrusted source to access a normally trustworthy or secure destination or to monitor or record the user interactions, thus introducing an additional vector of attack. Still further, malware may hijack the peripheral devices and corrupt or prevent access to them by the legitimate user.
Typically, each peripheral device is controlled by a respective device driver. The device driver is a software interface to the peripheral device that allows access the peripheral device, usually agnostically. Usually, any requests which are directed towards the peripheral device are made first to the device driver which, in turn, sends commands to the peripheral device. Conversely, data from the peripheral device is sent to the device driver and then forwarded to a requestor within the computer device. Device drivers are often individual to a particular peripheral device and may be operating system-dependent. Device drivers are often supplied by manufacturers of each peripheral device, but may also be provided by third parties.
Many operating systems include a kernel which manages requests that are directed towards each peripheral device, by allocating those requests to the respective device driver. The kernel may also provide interfaces for applications running on the computer device to access the peripheral devices. These interfaces are typically abstractions of the device drivers and isolate the device drivers from the applications. Hence, for an object-oriented operating system, peripheral devices may be represented as securable objects (often term ‘device objects’) for applications wishing to access them. Thus, for example, an application requesting data from the peripheral device makes a request to a device object representing the peripheral device. The request is subsequently allocated to the device driver by the operating system and the device driver in turn forwards corresponding commands to the peripheral device.
Most object-oriented operating systems also provide a mechanism to install and manage device drivers, and to create and manage device objects associated with the device drivers. Particularly, the operating system may provide a device object Application Program Interface (API) thereby allowing peripheral devices attached to the computer device to be detected, details of these peripheral devices to be retrieved, and properties of these peripheral devices to be set by the applications. In this way, the peripheral devices may be accessed and controlled by the applications running on the computer device.
As one example, in the Apple ‘OS X’ family of operating systems, a device object API is provided by IOKitLib API, comprising a set of functions that allow applications to access the peripheral devices through associated device interfaces. Particularly, a ‘driver object’ may be instantiated as a device object for a peripheral device connected to the computer device, through which the peripheral device may be accessed. Alternatively, POSIX API provides means of accessing the peripheral devices through associated device files.
In the Microsoft Windows family of operating systems, the device object API is provided by a ‘Windows Device Installation’ or SetupAPI, comprising a set of functions which provides means to manage device information sets and device objects. In this way, instance paths of device objects (together with associated friendly names) related to integral or external hardware devices attached to the computer device may be retrieved, allowing connected peripheral devices to be detected. For example, device object API function SetupDiGetClassDevs returns a device information set that contains all devices of a specified class; device object API function SetupDiEnumDeviceInterfaces returns a context structure for a device interface element of a device information set; device object API function SetupDiGetDeviceInterfaceDetail returns details about a particular device interface; device object API function SetupDiEnumDeviceInfo returns a context structure for a device information element of a device information set; and SetupDiGetDeviceRegistryProperty retrieves a specified Plug and Play device property. These device object API functions may provide information regarding any peripheral device that has ever been accessed by any application that has run on the computer device. However, those peripheral devices that are not currently connected may be readily filtered, if required.
In addition, the device object API may be employed to control access to peripheral devices. For example, on Microsoft Windows, device object API function SetupDiSetDeviceProperty may be used to set a device instance property; device object API function SetupDiCallClassInstaller may be used to call an appropriate class installer, and any registered co-installers, with a specified installation request; device object API function SetupDiSetClassInstallParams may be used to set or clear class install parameters for a device information set or a particular device information element; and device object API function SetupDiChangeState is a default handler for a DIF_PROPERTYCHANGE installation request. Particularly, device object API functions SetupDiSetClassInstallParams and SetupDiChangeState are required in order to change user access dynamically since Microsoft Windows will only apply device object security state changes when the computer device is rebooted if device object API function SetupDiSetDeviceProperty is called.
Notably, it is normally not possible to deny access to a particular peripheral device if that peripheral device is already being accessed, e.g. by a running application. Typically, the operating system does not dynamically apply a more restrictive access control than that applied at when the peripheral device was first accessed. Any restrictive access permissions are stored and applied at restart, before any application has acquired a handle to the peripheral device.
Considering these example arrangements for providing access to peripheral devices, it will be appreciated that malware may relatively easily identify which peripheral devices are connected to the computer device and to access these connected peripheral devices, e.g. using the device object API functions described above. In this way, malware may stealthily access information which is input to, or output from, the peripheral devices. Any one of these actions may provide an opportunity to perform malicious acts on the computer device.
In the related art, it is known to isolate untrusted content by limiting the resources of the computer device which are accessible by the untrusted content. A difficulty arises in that many of the current mechanisms for content isolation are relatively insecure, in that they still allow malicious content to reach important resources of the computer device. Also, many known implementations of content isolation are relatively resource intensive, such as by needing a relatively large amount of memory, disc space or computer processing power.
As a further difficulty, content isolation often requires a relatively skilled and knowledgeable user of the computer device. Therefore, it is quite difficult for an ordinary user to implement content isolation in a way which is safe, effective and reliable, yet also simple and intuitive. In some cases, content may need to be adapted in advance for the purposes of isolation, by being specifically prepared in a manner capable of being isolated, which increases costs and makes content isolation less likely to be implemented in practice.
The example embodiments have been provided with a view to addressing at least some of the difficulties that are encountered in current computer devices and computer networks, whether those difficulties have been specifically mentioned above or will otherwise be appreciated from the discussion herein.